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Foreword 


The  Geophysical  Airborne  Survey  System  (GASS)  is  a  distributed  micro¬ 
processor  system  that  integrates  magnetic,  hydrographic,  altitude,  position,  and 
attitude  sensors.  GASS  is  used  on  the  Project  Magnet  P-3  Orion  aircraft  operated 
by  the  Naval  Oceanographic  Office  to  collect  magnetic  and  hydrographic  data. 
The  magnetic  data  will  be  used  to  construct  isomagnetic  charts;  the  gravity 
data  will  be  used  to  improve  the  accuracy  of  inertial  navigation  charts.  Magnetic 
and  water  depth  data  will  be  used  to  upgrade  navigational  charts. 

This  report  summarizes  the  research  done  in  the  area  of  distributed  micro¬ 
processor  systems.  This  study  provides  a  foundation  for  the  design  of  GASS  and 
other  systems  of  this  type.  Details  of  the  final  GASS  design  are  provided. 
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Executive  Summary 


The  Geophysical  Airborne  Survey  System  (GASS),  developed  by  the  Naval 
Ocean  Research  and  Development  Activity*,  is  a  real-time,  distributed  micro¬ 
processor  sensor  system.  The  Naval  Oceanographic  Office  intends  to  use  this 
system  on  the  Project  Magnet  P-3  Orion  aircraft  to  collect  worldwide  magnetic 
and  hydrographic  data. 

This  report  briefly  discusses  the  mission  and  the  history  of  GASS  and  reviews 
the  technology  advances  of  the  last  decade  in  the  area  of  real-time  distributed 
microprocessor  systems.  Specific  topics  include  the  goals  of  distributed  system 
design,  the  qualitative  value  of  distributed  system  design,  and  reliable  design 
techniques  for  the  hardware  and  software  in  distributed  systems.  This  technology 
review  provides  a  foundation  for  the  GASS  design. 

The  systematic  design  decisions  made  for  GASS  are  detailed,  and  the  system's 
architecture  is  described.  Detailed  drawings  and  descriptions  of  the  hardware  and 
software  for  the  final  GASS  design  are  also  included.  Recommendations  are 
made  for  possible  system  enhancements  and  for  areas  that  require  further 
investigation. 
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Design  of  a  Distributed  Microprocessor  Sensor  System 


I.  Introduction 

This  report  discusses  the  design  of  the  Geophysical 
Airborne  Survey  System  (GASS).  To  this  end,  relevant 
research  in  the  area  of  real-time  distributed  processing 
systems  is  reviewed,  the  majordesign  considerations  of 
GASS  are  discussed,  and  the  final  design  is  presented  in 
detail. 

A.  The  System  and  Its  Mission 

The  GASS  is  a  sensor  system  built  around  a  distrib¬ 
uted  microprocessor  network.  This  design  was  chosen 
to  provide  a  high  degree  of  system  modularity.  Modu¬ 
larity  w  ill  enhance  the  system's  capability  to  be  flexible, 
available,  repairable,  and  updated  throughout  its  life 
span.  GASS  will  be  used  around  the  world  forsurveying 
tiie  earth's  magnetic  field  and  coastal  water  depths.  The 
magnetic  data  will  be  used  to  construct  isomagnetic 
charts,  and  the  gravity  data  will  be  used  to  improve  the 
accuracy  of  inertial  navigation  systems.  Both  the  mag¬ 
netic  data  and  the  water  depth  data  will  be  used  for 
navigational  charts.  In  addition  to  the  magnetic,  gravity, 
and  v.  ater  depth  sensors,  GASS  also  includes  position, 
altitude,  altitude,  and  time  devices  needed  to  correlate 
the  collected  data. 

B.  System  History 

The  GASS  is  designed  for  installation  on  the  Project 
Magnet  P  3  C  Irion  aircraft,  w  hich  is  ow  ned  and  operated 
by  the  Naval  Oceanographic  Office  (NAVOCEANO). 
Project  Magnet  was  initially  used  to  conduct  surveys  of 
the  earth's  magnetic  field1.  This  project  was  initiated  on 
a  trial  basis  by  the  Chief  of  Naval  Operations  in  1951, 
and  made  into  a  permanent  program  in  1957.  The  sensor 
system  was  upgraded  in  1970  by  the  Applied  Physics 
Laboratory  of  Johns  Hopkins  University,  and  was 
designated  the  Geomagnetic  Airborne  Survey  System. 
The  latest  version  of  the  system,  the  Geophysical 
Airborne  Survey  System,  will  be  used  to  collect  mag¬ 
netic  and  hydrographic  data.  Hydrographic  instruments 
are  included  in  the  system  because  of  the  200-ycar 
backlog  in  coastal  surveys  (coastal  surveys  arc  presently 
conducted  using  boats).  Gravity  data  will  also  be 


collected  with  this  system  when  airborne  gravimetric 
sensors  become  available.  The  new  GASS,  funded  by 
NAVOCEANO,  was  developed  by  the  former  Naval 
Ocean  Research  and  Development  Activity  (NORDA). 
(NOTE:  NORDA  has  been  designated  as  the  Naval 
Oceanographic  and  Atmospheric  Research  Laboratory). 
The  current  system  upgrade  project  began  in 
December  1986,  and  the  system  design  was  based  on 
the  state  of  the  technology  as  of  December  1987.  It  is 
estimated  that  60%  of  the  development  costs  will  be 
used  for  software  development  and  testing,  and  only 
40%  will  be  used  for  the  purchase  of  hardware.  The 
system  is  designed  for  a  life  expectancy  of  10  years. 

C.  Synopsis  of  Related  Work 

Distributed  processing  systems  for  real-time 
applications  are  becoming  a  reality  with  the  advent 
of  low-cost,  high-powered  microprocessors.  The  pro 
fessed  gains  of  a  distributed  system  are  many:  lower 
hardware  cost,  higher  reliability,  increased  flexibility, 
and  ease  of  modernization  and  expansion  due  to  the 
inherent  modularity.  Many  distributed  real-time  sys¬ 
tems  provide  proof-of-conccpt  for  this  design 
methodology.  Langley2  provides  the  results  of  the  work 
performed  under  Navy  contracts  to  create  a  distributed 
missile  guidance  and  control  system.  The  traditional 
use  of  analog  circuitry  and  single-processor  designs 
resulted  in  systems  that  were  difficult  and  expensive 
to  upgrade.  Langley's  goal  was  to  develop  a  modular 
architecture  that  would  increase  system  flexibility  and 
reduce  the  cost  of  software  development.  Wilcock3 
summarizes  the  concepts  for  the  development  of  dig¬ 
ital  control  systems  for  combat  aircraft.  This  joint 
effort  between  the  Royal  Aircraft  Establishment  and 
the  British  Aerospace  Corporation  was  to  develop  a 
distributed  processing  system  that  would  reduce  system 
weight,  reduce  pilot  workload,  improve  maintain¬ 
ability,  and  improve  survivability.  Shin4  discusses  the 
Distributed  Microprocessor  Airborne  Computing 
System  (DM  ACS)  that  was  developed  at  the  Rensselaer 
Polytechnic  Institute.  The  DMACS  is  designed  to  be  a 
combined  computer  system  for  high-performance 
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military  aircraft,  responsible  for  the  functions  of 
weapons,  navigation  and  control.  Feo5  outlines  the 
evaluation  requirements  for  Intelligent  Redundant 
Actuation  System  (IRAS)  designs.  IRAS  research  is 
NASA-sponsored  and  should  achieve  reduced  flight- 
control  computer  loading  by  shifting  the  tasks  of  failure 
isolation  and  configuration  management  to  micro¬ 
processors  at  the  actuator  level.  Shin6  discusses  the 
preliminary  research  of  the  Integrated  Multi-Robot 
System  (IMRS).  IMRS  is  a  distributed  processing  system 
designed  for  manufacturing  systems.  IMRS  is  expected 
to  outperform  contemporary  centralized  controllers  on 
the  basis  of  physical  space,  computer  capabilities, 
throughput,  flexibility,  and  fault-tolerance.  Gluch7  and 
Kieckhafer8  discuss  tire  Multicomputer  Architecture 
for  Fault-Tolerance  (MAFT)  developed  by  the  Bendix 
Aerospace  Technology  Center.  MAFT  was  designed 
for  maximum  reliability  in  real-time  control  systems.  It 
consists  of  sex  oral  nodes  connected  by  a  broadcast  bus 
network.  Each  node  uses  two  processors,  one  forcxccu- 
ti  vc  functions  and  one  for  applications  programs.  Fura’ 
disc  uses  the  Integrated  Fault-Tolerant  Avionics 
Systems  Computer  (IFT'AS)  developed  by  Boeing  for 
the  next  generation  of  space  transport  vehicles.  IFTAS 
is  a  distributed  network,  of  processing  nodes  intercon¬ 
nected  by  ••  high-speed  serial  bus.  Each  node  will  have 
from  one  to  four  processors  depending  upon  the  level  of 
reliability  required  by  its  functions.  One  of  the  most 
recent  and  s  gnificant  proponents  for  distributed 
processing  is  the  Space  Station  Columbus'  Data 
Management  System  (DMS);,',I'"IJ.  The  DMS  will  be 
responsible  lot  data  communications,  data  processing, 
data  administration,  data  storage,  data  retrieval, 
and  data  presentation  thiougnoul  the  space  station.  The 
c;  uttract  for  the  DMS  has  been  axvarded  to  McDonncll- 
L\  nights.  Their  proposed  design  w  ill  use  a  100-million 
bit  per  second  (Mbps),  token  ring,  fiberoptic  network 
that  will  connect  ail  of  the  processing  nodes  in  a  ring 
topology . 

W  hile  much  significant  work  has  been  done  in  die 
arc.;  <>!  real-time  distributed  processing  systems,  there 
is  still  no  clear-cut  methodology  for  designing  diese 
n\  stems.  Mej/,ak: '  points  out  that  the  distributed  system 
technology  has  not  yet  achieved  a  "rigid  definition." 
Only  a  few  attempts  have  been  made  to  quantize  the 
value  of  distributed  design  approaches. 

Pedar1*  presents  a  study  that  attempts  to  find  an 
optimal  tradeoff  among  fault  tolerance,  computing 
capacity,  and  cost  in  a  distributed  processor  system. 
Vielcanet'  provides  an  empirical  study  of  current  ground 
and  airborne  microprocessor-based  distributed  systems 
that  could  be  applied  to  space  systems.  Mangoubi16 


presents  a  method  for  evaluating  the  performance  of 
real-time  distributed  systems.  This  paper  was  a  joint 
effort  between  MIT  and  the  Draper  Laboratory,  and  it 
specifically  addresses  the  utilization  of  resources  and 
the  response  time  delays  for  processing  tasks.  Lala11 
presents  the  network  testbed  developed  by  Draper 
Laboratory.  This  testbed  will  be  used  to  experiment 
with  various  network  concepts  to  develop  more 
advanced  network  communication  systems  for  future 
spacecraft.  A  recent,  broad  research  effort  for  the  cost 
effectiveness  of  various  distributed  design  approaches 
has  been  undertaken  by  the  U.S.  Air  Force  with  its 
Modular  Avionics  System  Architecture  (MASA) 
program18.  Part  of  this  study  involves  determining 
what  level  of  modularity  can  best  benefit  the  Air 
Force.  Brock18  points  out  that  mandated  use  of  common 
modules  in  aircraft  systems  could  actually  result  in 
increased  weight,  size,  and  cost  over  an  optimum 
point  design. 

Intrinsic  to  any  discussion  of  distributed  real-time 
processing  systems  are  methods  of  achieving  fault 
tolerance.  The  most  common  method  for  achieving 
fault  tolerance  in  these  systems  is  through  redun¬ 
dancy  of  sensors,  actuators,  and  processors.  This 
redundancy  often  occurs  naturally  in  distributed 
processing  systems.  Cdderlccs19  describes  the  redun¬ 
dancy  management  of  the  Shuttle  Craft  flight  control 
system.  This  system  uses  quadruple  redundant  proces¬ 
sors  and  data  buses,  with  dual  and  triple  redundant 
sensors  and  actuators.  It  is  designed  to  continue  Safe 
operation  after  two  redundant  system  failures.  Watson3’ 
summarizes  the  work  performed  by  General  Dynamics 
in  the  development  of  a  reliable  avionics  control 
system.  Reliability  was  achieved  here  through  the  use 
of  redundant  sensors,  redundant  actuators,  redundant 
computers,  and  advanced  self-testing  features  within 
the  computers.  Sicvcrs21  discusses  the  development  of 
a  fault-tolerant  computer  for  the  U.S.  Navy.  He  claims 
that  the  use  of  fault-tolerant  architectures  can  achieve 
lifetime  costs  from  1/5  to  l/60ofthc  baseline  costs.  The 
architecture  proposed  involved  the  use  of  multiple 
single-board  computers,  which  would  run  identical 
tasks  and  periodically  check  each  other's  results. 
McGlonc22  summarizes  the  results  of  the  Air  Force's 
Full  Authority  Fault  Tolerant  Electronics  Engine 
Control  (FAFTEEC)  program.  This  program’s  goal  was 
to  develop  the  most  cost-effective  architecture  for 
reliable  digital  control  of  a  gas-turbine  engine.  The 
architecture  chosen  used  dual  sensors,  actuators,  and 
computers.  Each  computer  would  have  dual  central 
processing  units  (CPU)  to  determine  the  existence  of  a 
failure.  Hartman23  proposes  architecture  for  advanced 
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fly-by-wire  commercial  aircraft  systems.  This  work 
was  performed  by  Honeywell  under  a  contract  from  the 
Ames  Research  Center.  The  recommended  architecture 
involved  redundant  sensors,  actuators,  data  buses,  and 
processors.  The  processors  are  to  be  distributed 
throughout  the  system,  and  fault  tolerance  would  be 
implemented  using  cither  task  reassignment  or  parallel 
running  tasks  with  voting.  Dzwonczy24  presents  a  flight 
control  system  for  the  Entry  Research  Vehicle  (ERV). 
The  architecture  for  this  system,  developed  by  Draper 
Laboratory  and  Langley  Research  Center,  involves  the 
use  of  a  central  fault-tolerant  processor  that  is  con¬ 
nected  to  redundant  sensors  and  effectors. 

Fault  tolerance  through  redundancy  in  distributed 
processing  systems  is  typically  implemented  through 
the  use  of  multiple  identical  software  tasks  running  on 
separate  processors  with  some  form  of  voting.  An 
example  of  this  implementation  is  the  Software  Imple¬ 
mented  Fault-Tolerance  (SIFT)  Computer25.  This  form 
of  redundancy  places  more  of  a  software  burden  on 
the  system,  and  may  require  an  inordinate  amount  of  the 
computer  system's  throughput.  In  the  case  of  SIFT, 
the  executive  functions  of  the  computer  utilize  80% 
of  the  system  throughput8.  Because  of  the  disadvan¬ 
tages  of  software-intensive  fault  tolerance,  the  trend 
has  been  toward  hardware-intensive,  fault-tolerant 
schemes15.  The  goal  of  hardware-intensive  fault 
tolerance  is  to  provide  redundancy  that  is  "invisible"  to 
the  software  designer.  Montgomery26  discusses  a  fault- 
tolerant  microprocessor  that  uses  three  processing 
modules.  Each  module  is  made  from  two  microproces¬ 
sors,  and  upon  a  detected  module  failure  the  spare  is 
switched  in  and  the  system  is  restarted  using  a 
previously  stored  system  state  vector.  Evans27  discusses 
the  design  of  a  fault-tolerant  microcomputer  used  by 
the  Metro  Fire  Board  in  Melbourne,  Australia.  This 
system  uses  three  microprocessors,  each  with  identical 
peripheral  cards.  Under  fault-free  operations  two 
processors  perform  the  same  fault-critical  tasks  and  the 
third  is  used  for  noncritical  tasks.  If  a  discrepancy 
between  the  fault-critical  processors  occurs,  then  the 
computer  switches  to  a  voting  scheme  using  all  three 
processors.  Yaacob28  describes  a  fault-tolerant  micro¬ 
computer  that  meets  the  requirements  of  civil  avionics 
reliability.  This  design  uses  three  microprocessors 
wired  in  a  triply  modular  redundant  structure,  and  a 
fourth  processor  as  a  powered  standby  spare.  Smith29 
describes  the  design  theory  of  the  WG-DCS  machine 
developed  at  the  Draper  Laboratory.  This  machine  uses 
three  identical  processors  that  run  the  same  software. 
The  output  is  obtained  through  a  hardware  voting 
scheme.  Ichikawa30  describes  a  fault-tolerant  computer 


for  use  in  satellite  applications.  This  computer  will  use 
four  CPUs,  redundant  read-only  memory  (ROM), 
random-access  memory  (RAM),  clocks,  ports,  and  data 
buses.  Lala17  describes  a  quadruple-redundant  proces¬ 
sor  developed  at  the  Draper  Laboratory.  This  processor 
has  been  designed  to  maintain  fault- free  operation  in 
die  event  of  any  single  point  failure.  As  discussed  by 
Lala17,  there  have  been  instances  of  failures  in  triply 
redundant  flight  control  systems.  Quadruple  redundance 
is  required  to  maintain  fault-free  operation  in  the 
presence  of  a  single  Byzantine  (malicious)  failure31. 

An  abundance  of  research  has  been  conducted  on  the 
development  of  software  methods  that  will  improve 
the  reliability  of  real-time  distributed  systems.  Two  of 
these  methods,  multiversion  software  and  recovery 
blocks,  are  intended  to  prevent  system  failures  due  to 
undetected  residual  programming  errors.  The  multi¬ 
version  software  method  involves  writing  several 
different  versions  of  the  same  software  task.  If  one 
version  fails,  then  the  other  versions  will  maintain 
system  operation.  The  recovery  block  method  involves 
periodically  saving  the  system’s  state  vector  and,  in  the 
event  of  a  failure,  restarting  the  system  at  its  last 
saved  state.  A  third  method,  specifically  designed  for 
distributed  systems,  is  relocatable  software.  This 
software  method  enables  a  distributed  processor 
system  to  tolerate  hardware  faults  by  relocating  the 
tasks  of  the  failed  processors  to  operational  proces¬ 
sors.  Multiversion  software  for  real-time  systems 
is  discussed  by  Shepherd32,  Hitt33,  Avizienis34,  and 
Kieckhafer8.  Recovery  Block  techniques  for  real-time 
systems  are  discussed  by  Anderson35,  Schneider36,  and 
Hitt33.  Clarke37,  Schmid38,  Loques39  and  Best40  discuss 
the  use  of  relocatable  software  for  real-time  systems. 

Despite  the  research  that  has  been  done  on  multi¬ 
version  software  and  on  recovery  blocks,  risks  posed  by 
these  methods  are  still  generally  considered  too  high  for 
use  in  distributed  systems.  Eckhardt41  indicates  that 
there  are  no  data  available  to  determine  the  cost 
effectiveness  of  multiversion  software,  even  though 
this  method  is  used  in  the  space  shuttle  and  in  Canadian 
Nuclear  Reactor  systems.  Voigt42  states  that  exhaus¬ 
tive  testing  is  the  only  effective  method  to  dale  for 
generating  reliable  software.  Avizienis34  notes  that 
multiversion  software  has  been  used  in  flight  control 
systems  for  the  Boeing  737/300,  the  Airbus,  and  the  ATR 
aircraft.  The  authors  of  this  paper  reviewed  the  results 
of  a  University  of  California  at  Los  Angeles  (UCLA) 
and  UC-Irvine  study  on  multivcrsion  software.  The 
UCLA  results  were  promising,  but  the  UC-Irvinc 
study  cast  serious  doubt  about  the  effectiveness  of  this 
method.  At  present,  the  only  well-accepted  method  for 
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preventing  system  failures  due  to  residual  software 
errors  is  through  extensive  testing.  A  study  for  the 
Netherlands  Department  of  Civil  Aviation43  indicates 
that  since  software  reliability  cannot  be  accurately 
determined,  reliable  software  development  requires 
rigorous  development  procedures  and  extensive  test¬ 
ing.  It  is  generally  accepted  that  a  large  percentage  of 
the  residual  errors  can  be  eliminated  before  testing 
through  strict  adherence  to  a  software  quality  assurance 
program  during  software  development.  An  intensive 
study  performed  by  Lear  Sicgler  Inc.  during  the  devel¬ 
opment  of  the  Boeing  737/3CX)  Flight  Management 
Computer  System  (FMCS)  indicated  that  40%  to  50% 
of  the  errors  detected  during  the  debugging  process 
could  have  been  detected  during  functional  testing  of 
software  modules44.  The  Department  of  Defense 
standard  DoD-STD-2168,  discussed  by  Cooper45  and 
Smith44',  outlines  a  method  for  ensuring  software  quality 
through  an  active  quality  assurance  program.  A  similar 
methodology  is  also  used  in  I  F.EE  Standard  983,  "Guide 
for  Software  Quality  Assurance  Planning"  and  in  a 
report  by  the  European  Space  Research  and  Technology 
Centre  on  softw  are  quality4'.  It  is  evident  that  the  use  of 
Computer  Aided  Software  Engineering  (CASE) 
packages  throughout  the  specification,  design, 
development,  testing,  and  maintenance  of  software  can 
haw  a  great  impact  on  its  reliability  and  lifetime  cost. 
CASE  packages  can  be  used  to  enforce  a  quality  assur¬ 
ance  by  providing  a  manageable  program  throughout 
the  software  life  cycle. 

In  summers ,  there  is  ample  evidence  that  distributed 
pt ocewsing  can  produce  a  system  that  is  lower  in  cost, 
has  higher  reliability,  and  greater  flexibility  than  a 
vcntrali/ed  processing  system.  However,  there  is  little 
more  if.. m  empirical  data  available  to  the  systems  engi¬ 
neer  lor  the  optimal  design  of  a  distributed  system, 
partly  because  design  of  an  embedded,  real-time, 
distributed  system  is  highly  application-specific.  While 
a  distributed  design  can  be  used  to  achieve  a  more 
cos:  effective  solution,  it  is  often  unclear  how  to 
optimize  the  design  solution  lor  the  greatest  benefit. 
Hie  design  is  typically  balanced  between  the  system 
cost  and  the  acceptable  level  of  reliability/ncxibility. 
The  only  proven  method  of  achieving  reliability  in  a 
distributed  sy  stem  is  through  hardware  redundancy. 
Several  software  methods  of  improving  system  reliabil¬ 
ity  have  been  proposed,  but  their  value  is  questionable. 
A  current  trend  is  toward  the  development  of  highly 
reliable  processors  that  achieve  fault  tolerance  through 
hardware  methods.  These  processors  would  provide 
very  high  levels  of  fault  tolerance  while  placing  little  or 
no  extra  burden  on  the  software  designers.  Software 


development  continues  to  be  the  greatest  hurdle  for 
distributed  systems  design,  with  exhaustive  testing  the 
only  accepted  method  for  producing  reliabie  soltwarc. 
Since  exhaustive  testing  of  a  complex  software  system 
often  requires  an  inordinate  amount  of  time,  the  on'y 
feasible  approach  to  reliable  software  development  is 
through  a  highly  structured  development  prtKcss. 

Section  II  discusses  the  design  of  GASS,  detailing 
the  functions  required  of  the  system,  the  system's  design 
constraints,  and  the  development  of  an  architecture  that 
will  satisfy  both  the  requirements  and  constraints. 
Section  III  provides  in-depth  details  of  the  final  GASS 
design,  including  a  description  of  the  hardware  and 
software  paths  traversed  by  a  sensor  datum.  Section  IV 
summarizes  the  major  points  of  this  report.  Section  V 
provides  recommendations  for  areas  in  GASS  that 
require  further  investigation  and  recommends  future 
system  enhancements. 

II.  System  Design 

A.  System  Functions 

Figure  1  illustrates  the  basic  and  essential  functions 
that  are  required  of  GASS.  The  primary  function  of 
GASS  is  to  collect,  format,  and  time  stamp  data  from  the 
sensors  and  to  record  these  data  onto  magnetic  tape. 
The  magnetic  tape  contains  all  data  measured  by  the 
sensors,  and  these  data  arc  loaded  later  onto  a  home- 
base  computer  for  analysis.  The  secondary  function  of 
GASS  is  to  provide  centralized  control  and  monitoring 
of  its  sensors  and  ancillary  equipment.  Including  con¬ 
trol  in  the  functions  of  GASS  tremendously  escalates  its 
complexity.  However,  over  30  devices  w  ill  be  included 
in  GASS,  many  of  w  hich  arc  extremely  complicated  to 
operate.  Centralizing  control  and  monitoring  of  all  the 
devices  in  the  system  will  reduce  the  manning  and 
training  levels  required  to  operate  the  system.  The 
tertiary  function  of  GASS  w'ill  be  navigation.  Since 
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GASS  is  to  be  used  for  surveying,  »ui  vey  tiacks  must  be 
generated  and  followed.  Furthermore,  deviations  of  the 
aircraft  from  the  planned  track  can  invalidate  the  data 
collected;  the  system  operator  must  be  alerted  if  the 
aircraft  strays  too  far  from  the  designated  track.  GASS 
navigation  functions  must  include  generating  and  edit¬ 
ing  survey  plans,  ascertaining  the  aircraft's  position 
from  its  sensors,  displaying  aircraft  position  relative  to 
the  survey  plan  to  the  system  operator  and  the  pilot,  and 
keeping  a  navigation  log.  The  navigation  log  is  a  backup, 
on  magnetic  media,  of  the  aircraft's  track.  This  informa¬ 
tion  can  be  used  to  resume  a  survey  in  the  event  of  a 
system  malfunction.  A  supplementary  function  of 
GASS  will  be  data  analysis.  GASS  will  have  the  ability 
to  perform  analysis  of  data  previously  recorded  on 
magnetic  tape,  or  to  analyze  data  in  near  real  time  as  it 
is  collected  from  the  sensors. 

B.  Design  Requirements 

Typical  avionic  system  requirements  involve  size, 
weight,  power  consumption,  and  electromagnetic 
interference  considerations.  To  meet  these  require¬ 
ments  an  avionic  system  is  usually  custom-built  for  a 
particular  application  The  original  GASS,  built  by  the 
Applied  Physics  Laboratory  of  Johns  Hopkins 
University,  consisted  of  many  custom-made  devices 
and  interfaces.  This  design  methodology  tends  to  make 
a  system  very  difficult  to  maintain  and  modernize.  The 
need  for  the  current  redesign  of  the  system  is  a  direct 
consequence  of  the  previous  system  design.  The 
components  in  the  original  system  can  no  longer  be 
maintained  due  to  lack  of  technical  support,  and  the 
system  was  not  designed  to  allow  for  modernization. 
The  primary  design  constraint  put  forth  by 
NAVOCEANO  for  the  new  GASS  is  that  the  system  be 
constructed  with  a  highly  modular  architecture,  using 
off-the-shelf  components  if  possible.  NAVOCEANO 
desired  a  system  that  would  be  easily  reconfigured 
for  different  survey  missions,  but  most  of  all,  they 
desired  a  system  that  would  allow  easy  integration  of 
state-of-the-art  sensors  as  they  become  available. 

The  mission  of  GASS  will  often  take  it  to  remote 
areas  of  the  world,  distant  from  technical  support 
activities.  As  a  consequence,  NAVOCEANO  desired 
that  the  system  be  designed  for  maximum  reliability. 
However,  since  a  failure  in  GASS  cannot  result  in 
personnel  injury  or  equipment  damage,  it  was  not 
deemed  necessary  to  include  extensive  fault  tolerance 
in  the  system.  System  fault  tolerance  requires  equip¬ 
ment  redundancy,  which  significantly  affects  the 
cost  and  weight  of  the  system.  The  design  sought, 
then,  should  improve  system  reliability  through  fault 


detection/isolation  and  through  system  availability.  The 
fault  detection  and  isolation  capabilities  of  GASS  arc 
discussed  in  depth  by  Bourgeois4®.  With  advanced  fault 
detection  and  isolation  features,  a  system  will  quickly 
alert  the  operator  of  any  irregularities.  High  availability 
implies  that  while  system  operation  may  be  interrupted 
by  failures,  the  system  may  be  easily  and  quickly 
placed  back  into  operation.  A  high  degree  of  system 
availability  can  be  achieved  through  an  architecture 
that  allows  easy  reconfiguration  of  the  system  into  a 
degraded  operating  mode.  Thus,  reliable  system  design 
for  GASS  will  entail  a  system  that  will  rapidly  detect 
and  announce  failures,  and  allow  for  rapid  reconfigura¬ 
tion  to  a  degraded  operating  mode  so  that  the  survey 
may  be  continued  with  minimum  impact. 

C.  System  Architecture 
1.  Number  of  Processors 

One  of  the  first  items  that  must  be  established  about 
the  design  of  a  system  of  this  type  is  the  number  of 
processing  elements  that  will  be  required.  As  shown  in 
Figure  2,  two  extremes  are  possible:  a  single  processor 
interfaced  to  all  of  the  equipment  in  the  system,  or  a 
design  where  each  piece  of  equipment  has  a  processor 
and  all  processors  are  connected  to  a  network.  If  only 
the  data  acquisition  tasks  are  considered,  then  a  single 
microprocessor  should  be  able  to  handle  the  computa¬ 
tional  load.  With  approximately  20  sensors  and  related 
instruments  in  GASS,  and  a  maximum  sampling  rate 
per  sensor  of  16  Hz,  there  are  approximately  320  data 
acquisition  tasks  must  be  performed  each  second.  If  a 
16.7-MHz  microprocessor  (Motorola  MC68020)  were 
to  be  used  for  this  application,  then  nearly  50,000  proc¬ 
essor  cycles  would  be  available  for  each  acquisition 
task.  A  crude  estimate  is  five  cycles  on  the  average  per 
instruction  for  the  MC68020,  so  nearly  10,000  instruc¬ 
tions  per  acquisition  task  are  allowed.  If  only  the 
acquisition  tasks  were  required,  then  a  single  MC68020 
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processor  would  probably  suffice.  However,  in  addition 
to  the  basic  acquisition  tasks  are  the  tasks  for  the  tape 
recorder,  navigation  processing,  operator  interfaces, 
and  other  system  control  functions.  The  addition  of 
these  tasks  would  make  it  difficult  to  operate  the  system 
with  a  single  processor.  Also,  the  use  of  a  single  proc¬ 
essor  creates  a  monumental  single  point  failure 
vulnerability  in  the  system. 

The  other  extreme  would  be  to  use  a  processor  for 
each  component  in  the  system,  with  each  processor 
interfaced  to  a  central  bus  system.  The  low  cost  of 
microprocessors  would  make  this  approach  feasible 
and.  if  a  proper  design  is  used,  then  muluple  micro¬ 
processors  can  reduce  the  effect  on  the  system  of 
a  single  failed  processor.  However,  the  constraint  on 
GASS  for  the  use  of  off-the-shelf  components  restricts 
this  approach.  A  processor  per  instrument  is  most 
attractive  if  a  custom  "black  box"  (typically  a  single 
circuit  card)  can  be  built  that  will  interface  the 
component  directly  to  the  central  data  bus.  Use  of  off- 
the-shelf  components,  however,  would  require  a 
separate  microprocessor  card,  an  interface  card,  and 
a  card  cage  for  each  device.  The  result  is  that  more 
circuit  cards  would  be  required,  and  the  overall  system 
pow  e  r  requirement  w  ould  be  greater.  As  a  consequence, 
the  decision  was  made  to  use  "several"  microprocessors, 
Nomow  here  between  the  twoc  xtremes.  The  exact  number 
of  processors  needed  depends  mainly  upon  how  and 
where  they  are  to  be  used  in  the  system,  as  discussed  in 
lIic  next  section, 

2.  Centralized  vs.  Distributed  Hardware 

With  the  choice  to  use  multiple  processors  made,  a 
decision  must  be  made  about  how  these  processors  will 
be  arranged  in  the  system.  Two  general  methods  arc 
available:  centralized  or  distributed.  A  centralized 
system  offers'  the  advantage  that  a  single  card  cage  can 
be  used.  This  system  allows  for  higher  communication 
rates  between  processors  on  a  backplane  bus  system, 
the  elimination  of  the  hardware  and  software  required 
to  network  distributed  processors,  and  a  reduction  in  the 
number  of  power  supplies  required  for  the  system. 
The  disadvantages  of  a  centralized  system  include  single 
point  failure  vulnerability  and  a  more  scv_ie  wiring 
problem.  With  a  centralized  system  the  interface  cables 
must  be  run  from  each  sensor  to  the  computer  system. 
This  configuration  results  in  much  more  weight  and 
bulk  over  that  which  would  be  required  for  a  network- 
connected,  distributed  system.  This  problem  has 
already  caused  many  high-performance  fighter  aircraft 
manufacturing  firms  to  seriously  consider  using 
distributed  systems.  The  single  point  failure 
disadvantage  is,  without  question,  the  single  greatest 


problem  with  centralized  systems.  Not  only  can  the 
entire  system  be  halted  by  a  failure  of  the  central 
computer's  power  supply,  but  failures  in  remote  parts 
of  the  system  can  disrupt  operations.  An  extreme 
example  of  this  problem  has  been  displayed  by  the 
Main  Engine  Control  System  for  the  FFG7  Class  (Fast 
Frigate  with  guided  missiles)  of  naval  ships,  designed 
by  the  General  Electric  Ground  Systems  Division.  The 
system  is  used  to  control  the  operation  of  the  two  main 
propulsion  gas  turbine  engines  and  their  ancillary 
equipment.  A  centralized  system  is  used,  with  all  sensor 
and  actuator  signals  routed  to  the  central  computer. 
Component  failures  remote  to  the  computer  can  cause 
unwanted  voltages  to  appear  on  the  component's  return 
signal  lead,  which  is  common  to  the  entire  system.  At 
best,  the  result  would  be  an  inoperative  system. 
Unfortunately  the  result  would  typically  be  erratic  and 
undesirable  system  operation. 

Distributed  systems  can  nearly  eliminate  the  prob¬ 
lem  of  single  point  failures.  In  a  distributed  system  the 
tasks  performed  by  the  system  arc  distributed  among 
several  processors,  called  "nodes,"  interconnected  by  a 
network.  Network  interfaces  are  available  that  allow 
a  system  to  completely  disregard  faulty  nodes.  If  the 
system  is  designed  to  reduce  inter-nodc  dependencies, 
then  the  failure  of  a  single  processor  can  have  little  or  no 
effect  on  the  rest  of  the  system.  A  distributed  system 
reduces  the  wiring  bulk  by  placing  the  processing 
elements  nearer  to  the  remote  system  components,  and 
the  processing  elements  can  be  connected  with  cither  a 
single  twisted  pair  of  wires,  a  coax  cable,  or  a  fiber-optic 
cable.  This  wiring  configuration  also  reduces  a  system’s 
vulnerability  to  electromagnetic  interference. 

A  distributed  system  increases  availability  in  that  a 
single  faulty  node  will  not  affect  the  rest  of  the  system. 
Furthermore,  if  the  system  is  so  designed,  then  the  tasks 
of  a  faulty  node  can  be  redistributed  to  the  functional 
nodes.  Disadvantages  of  a  distributed  system,  in  light  of 
the  requirement  for  off-the-shelf  components,  are  that  a 
separate  card  cage,  each  with  its  own  power  supply  and 
network  interface  card,  must  be  used  for  each  remote 
processing  node.  The  decision  was  made  to  use  a 
distributed  design  for  GASS,  because  of  its  reliability 
aspects.  To  reduce  the  cost  incurred  by  the  support 
equipment  required  at  each  node,  only  eight  nodes  will 
be  used.  Six  of  these  nodes  will  interface  to  sensors,  the 
seventh  node  will  be  used  for  the  operator  and  tape 
recorder  interlaces,  and  the  eighth  node  w  ill  handle  the 
data  analysis  functions.  'Hie  six  sensor  nodes  will  be 
designed  to  pros  10.  the  computational  [Ktwcr  needed  by 
the  current  sensor  complement,  and  to  allow  addition  of 
more  sensors  With  six  sensor  nodes,  there  will  be  an 
approximate  loading  ot  only  three  devices  per  node. 
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This  number  leaves  ample  processing  power  for  the  task 
of  bus  communications,  some  minor  data  processing, 
and  the  addition  of  more  sensors. 

3.  Local  A  ca  Network 

Since  the  system  will  be  constructed  using  a  distrib¬ 
uted  architecture,  a  communications  media  must  be 
chosen  to  interconnect  the  processors.  The  IEEE-488 
standard,  or  general-purpose  interface  bus  (GPIB), 
would  seem  the  natural  choice  for  this  application. 
However,  the  GPIB  poses  severe  limitations  that  make 
the  use  of  a  net  work- type  communications  system  much 
more  attractive.  The  GPIB  has  a  limitation  of  15  devices 
per  bus,  and  the  maximum  length  of  cables  used  for  a 
bus  must  not  exceed  20  m49.  Also,  the  GPIB  cable  is 
much  heavier  and  bulkier  than  a  single  twisted  pair  or 
a  coax  cable.  The  GPIB  cannot  be  easily  upgraded  to  a 
faster  communication  media;  a  coax  network  could 
easily  be  upgraded  to  a  faster  fiber-optic  network. 
Because  of  the  GPIB  limitations,  the  decision  was  made 
to  use  a  network  based  on  a  serial  data  bus  to  intercon¬ 
nect  the  processor  nodes. 

Three  fundamental  local  area  network  (LAN) 
configurations  arc  practical  for  use  in  an  embedded 
real-time  avionics  system;  die  ring,  the  star,  and  the  bus 
(Fig.  3).  In  the  ring  bus,  which  is  commonly  unidirec¬ 
tional,  messages  arc  circulated  around  the  ring  until 
they  reach  the  target  node(s).  This  protocol  greatly 
simplifies  message  routing;  and,  since  more  than  one 
message  can  be  in  transit,  very  high  data  rates  can  be 
achieved5*'.  The  ring  bus  is  well  adapted  for  systems 


consisting  of  highly  autonomous  nodes.  Since  all 
the  sensor  nodes  in  GASS  must  communicate  with  the 
single  node  that  has  the  tape  recorder  and  the  operator 
interface,  the  nodes  of  GASS  cannot  be  considered 
autonomous.  Therefore,  the  ring  bus  is  not  an 
efficient  choice  for  this  application.  Ihc  star  bus,  with 
the  operator/rccordcr  node  of  GASS  placed  at  the 
center,  would  seem  the  most  natural  choice  for  this 
system.  The  advantage  of  a  star  configuration  is  that  it 
can  achieve  the  highest  data  rates  of  all  me  possible 
architectures.  The  disadvantage  of  the  star  configura¬ 
tion  is  that  the  center  node  would  require  an  interface 
card  for  each  remote  node.  The  bus  configuration  offers 
a  system  with  less  hardware  but  slower  data  rates,  since 
several  nodes  must  share  the  same  communication 
media.  The  bus  is  the  typical  choice  for  avionics 
systems  because  of  the  savings  in  hardware”.  A  single 
bus  architecture  was  selected  as  the  economical  choice 
for  the  GASS  network,  since  each  node  will  have  the 
ability  to  buffer  collected  sensor  data  between  bus 
transmission  periods. 

When  a  network  is  used  for  communications,  a 
Media  Access  Protocol  (MAP)  must  be  established. 
There  arc  two  fundamental  MAP's,  contention  and 
noncontention50.  With  a  contention  MAP,  also  known 
as  random-access  MAP,  all  nodes  have  equal  access 
rights  to  the  network.  The  most  commonly  known 
network  of  this  type  is  Xerox's  Ethernet.  A  node  gains 
access  to  the  network  by  listening;  if  the  network  is 
silent,  then  it  will  proceed  to  transmit.  Since  there  arc 
propagation  delays  across  the  wiring  in  a  network,  two 
nodes  may  begin  transmissions  simultaneously, 
resulting  in  a  "collision."  Collision  is  the  greatest 
disadvantage  of  a  contention  MAP.  and  its  occurrence 
makes  this  protocol  unsuitable  for  real -time  applications. 
Current  research,  however,  indicates  that  the  problems 
of  collision  in  random-access  networks  may  soon  be 
remedied51-52. 

With  a  nonconlcntion  MAP,  some  method  is  used  to 
ensure  dial  only  one  node  is  transmitting  on  die  network 
at  any  given  lime.  The  two  common  methods  for 
implementing  a  noncontention  MAP  are  bus  controller 
and  token  passing.  With  a  bus  controller  MAP,  a  single 
node  is  given  the  responsibility  to  control  all  network 
communications.  Other  nodes  arc  instructed  to  transmit 
data  packets  by  the  controller  node.  The  greatest 
advantage  of  this  scheme  is  its  inherent  simplicity  of 
implementation.  The  disadvantages  arc  that  it  docs  not 
make  maximum  use  of  the  bandwidth  of  the 
communication  media,  and  i!  presents  a  single  point 
failure  vulnerability.  The  lime-slot  implementation  is 
the  typically  used  controller  scheme,  where  each  remote 
node  is  allotted  a  period  of  time  for  transmission  by  the 
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controllei.  Inefficiency  exists  with  this  implementation 
since  a  node  may  be  granted  its  time-slot  even  if  it  has 
no  data  to  transmit.  The  token-passing  MAP  has  received 
much  attention  in  recent  years5W0,  and  it  provides  for 
more  efficient  use  of  the  network  medium.  With  a  token 
passing  MAP  a  token  is  circulated  from  node  to  node 
throughout  the  network.  The  node  that  possesses  the 
token  is  allowed  to  transmit  on  the  bus  and,  when  it  no 
longer  needs  network  access,  it  is  responsible  for 
passing  the  token  to  the  next  node.  The  noncontention 
controller  MAP  was  chosen  for  GASS  because  of  its 
simplicity  of  implementation  and  because  the  system 
architecture  is  such  that  all  sensor  nodes  will  communi¬ 
cate  with  the  operator/recorder  node  but  not  with  each 
other.  The  problem  of  single  point  failure  vulnerability 
presented  by  this  MAP  can  only  be  resolved  by  using  an 
additional  node  with  a  tape  recorder  as  an  online 
backup  for  die  controller  node.  The  cost  in  terms  of 
expense,  weight,  and  size  make  this  solution  unaccept¬ 
able  for  GASS.  As  discussed  in  the  next  section,  the 
analysis  node  will  be  used  as  an  off-line  backup  for 
the  controller  node. 

4.  Physical  and  Functional  Partitioning 
of  Software 

The  hardware  design  concept  consists  of  eight  proc¬ 
essing  nodes  interconnected  by  a  bus  network  that  uses 
a  controller  MAP.  Six  of  the  nodes  will  be  used  for 
sensors.  The  seventh  node  will  be  used  for  the  operator 
interface  and  the  magnetic  tape  recorder.  The  eighth 
node  will  contain  the  data  analysis  function*.  Since  all 
sensor  nodes  need  to  communicate  with  the  operator/ 
recordei  node,  but  not  with  each  other,  the  network 
controller  function  will  be  located  in  the  operator/ 
recorder  node.  All  that  remains  to  be  defined  for  the 
system's  architecture  is  the  placement  of  the  various 
software  tasks  required  to  operate  the  system. 

The  software  tasks  required  for  this  system  include 
bus  interface  tasks  at  each  node,  operator  interface  tasks 
( keyboard,  displays,  etc.),  and  a  tape  recorder  task  at  the 
operator/recordei  node,  sensor  control  and  acquisition 
tasks,  navigation  tasks,  and  data  analysis  tasks.  To 
maximize  real-time  performance,  the  software  tasks 
should  be  physically  and  functionally  partitioned.  In 
other  words,  the  software  should  be  designed  to  be 
modular  in  form.  To  meet  this  goal  all  sensor  tasks  are 
completely  isolated  to  the  sensor  nodes.  They  will  be 
designed  such  that  all  sensors  appear  to  be  identical 
from  the  perspective  of  the  opcrator/rccordcr  node 
and  from  the  bus  interface  task  in  each  node.  More 
specifically,  the  individual  sensor  task  in  a  sensor  node 
will  be  the  only  software  that  i;  aware  of  the  actual 
details  of  operation  of  its  particular  sensor.  To  the  rest 
of  the  system,  the  sensor  will  have  only  the  basic 


functions  of  sampling  or  not  sampling,  sampling  rate, 
and  initialization.  By  placing  all  of  the  "intelligence"  to 
operate  a  sensor  only  at  the  sensor’s  node,  network 
communications  are  decreased  and  the  speed  of  the 
sensor  task  is  increased,  since  it  is  not  dependent  upon 
the  network.  Furthermore,  data  from  all  sensors  will  be 
packaged  identically,  eliminating  special  handling 
requirements  insofar  as  the  bus  interface  and  tape 
recorder  tasks  are  concerned.  This  software  approach 
also  offers  the  advantage  that  all  bus  interface  tasks  will 
be  identical.  This  method  will  reduce  the  cost  of  soft¬ 
ware  development  and,  since  the  same  module  will  be 
used  by  several  developers  in  different  nodes,  it 
provides  more  thorough  debugging  of  the  software 
module.  Another  advantage  1*  that  the  highly  modular 
sensor  tasks  may  be  easily  relocated  to  different  nodes 
within  the  system. 

To  reduce  the  possibility  of  a  bottleneck  in  the 
network,  the  decision  was  made  to  use  two  microproc¬ 
essors  in  the  operator/rccorder  node.  One  processor 
would  be  used  strictly  for  the  bus  interface  and  the 
recorder  interface  to  minimize  the  time  required  to  pass 
data  from  the  network  to  the  tape  recorder.  The  real¬ 
time  processor  would  handle  all  communications  on  the 
network,  and  would  pass  the  required  control  and  data 
information  between  the  network  and  the  operator 
interface.  The  second  processor  would  be  used  for  the 
operator  interface,  which  is  a  less  time-critical  function: 
This  processor  is  the  logical  location  for  the  navigation 
task,  which  is  predominantly  an  off-line  task,  requiring 
only  occasional  position  data  from  the  sensors.  Since 
data  analysis  tasks  are  typically  computationally  inten¬ 
sive,  a  separate  processor,  isolated  from  the  real-time 
elements  of  the  system,  should  be  used.  The  need  to 
isolate  potentially  slow  software  tasks  from  the  rest  of 
the  system  was  the  primary  reason  for  using  a  separate 
node  for  the  data  analysis  tasks.  Since  data  analysis  will 
be  performed  on  a  separate  node,  this  node  must  also 
include  the  hardware  and  the  software  tasks  to  receive 
real-time  data  from  the  network  or  to  read  data  tapes 
recorded  by  the  opcrator/rccordcr  node.  The  data 
analysis  node  will  thus  require  much  of  the  same 
hardware  and  software  as  the  opcrator/rccordcr  node,  so 
these  two  nodes  were  made  using  identical  hardware. 
Data  analysis  is  a  nonvital  task  in  GASS  and,  in  the 
event  of  a  failure  of  the  opcrator/rccordcr  node,  this 
design  scheme  would  allow  the  data  analysis  node  to  be 
used  for  control  of  the  system. 

The  resulting  architecture,  illustrated  in  Figure  4,  has 
the  software  tasks  physically  and  functionally  parti¬ 
tioned.  The  highest  speed  tasks,  those  of  sensor  control 
and  data  acquisition,  arc  located  only  in  the  six  sensor 
nodes.  The  next  highest  speed  requirement  is  that  of 
moving  the  data  from  the  sensors  to  the  tape  recorder. 
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Figured.  GASS  architecture . 


This  requirement  is  handled  by  bus  interface  tasks  in 
each  sensornodc,  and  the  bus  and  tape  recordertasks  are 
handled  on  the  real-time  processor  in  die  operator/ 
recoi  dcr  node .  The  slowest  tasks,  operator  interface  and 
navigation,  arc  handled  in  the  second  opcrator/rccorder 
node  processor,  which  is  physically  separated  from  the 
real-time  processor  by  a  global  memory  area.  All 
communications  between  the  two  processors  in  this 
node  will  be  handled  through  the  global  memory, 
reducing  the  load  on  the  real-time  processor.  The  data 
analysis  node  will  function  independently  from  the  rest 
of  the  system,  and  will  "listen"  to  the  system's  network 
to  receive  real-time  data  from  the  sensors. 

D.  System  Building  Blocks 

1.  Microprocessor/Backplane 
The  choice  for  die  backplane  bus  system  was  largely 
driven  by  the  requirement  to  use  off-the-shelf 
components,  and  die  desire  to  use  a  32-bit  data  and 
address  bus.  The  oldest  32-bit  microprocessor  standard 
bus  is  the  Motorola  VME  bus  system  introduced  in  198 1 
(also  known  as  IEEE  Standard  P1014)61.  The  VME  bus 
had  the  greatest  market  support  at  the  time  of  the  GASS 
design  and  was  chosen  as  die  microprocessor  backplane 
bus  system.  As  a  consequence,  despite  the  diverse  array 
of  sensors  used,  only  3  of  the  17  interface  cards  in  the 
system  had  to  be  custom-made.  Since  the  VME 
backplane  was  selected,  a  natural  choice  for  a  micro¬ 
processor  was  the  Motorola  MC68020.  The  MC68020 
is  a  state-of-the-art  microprocessor  that  supports  multi¬ 
tasking,  and  the  68000  family  of  processors  have  been 
used  in  aerospace  applications  by  Plesscy  Avionics62 
and  Draper  Laboratory 17Z4H.  It  was  the  second  most 
preferred  microprocessor  (after  the  MIL-STD-750A) 
of  Ada  development  tool  manufacturers64. 


2.  Local  Area  Network  Medium 

The  LAN  medium  selected  by  NAVOCEANO  wi¬ 
the  Military  Standard  1553B  serial  bus,  the  data  bus  of 
choice  for  military  avionic  systems  (and,  dius,  a  large 
industrial  backing).  It  supports  1-Mbps  operation, 
transformer  isolation  of  nodes,  and  offers  the  feature  of 
dual-redundant  comr  lication  channels.  A  possible 
alternate  bus  would  be  the  Avionics  Standard 
Communication  Bus  (ASCB)65.  ASCB  was  developed 
by  Sperry  Corporation  and  is  supported  by  the  General 
Aviation  Manufacturers  Association  (GAMA).  It  is 
also  a  dual-redundant  bus  s>  'em  for  avionics 
applications,  and  supports  0.67  Mbps  operation  at  a 
reduced  cost.  The  chief  advantages  of  the  1553B  bus- 
over  the  ASCB  is  that  1553B  has  broader  industrial 
support,  and  fiber-optic  upgrades  for  1553B  systems 
are  already  available66. 

3.  Operating  Systems 

Unix  (Motorola  V.3)  was  chosen  as  the  operating 
system  for  the  operator  interface  processor.  Unix  is  a 
well-established,  multitasking  operating  system  with 
which  the  system’s  designers  were  well  acquainted.  A 
full-capability  operating  system  is  needed  for  the 
operator  interface  processor,  since  it  is  responsible  for 
standard  microcomputer  tasks,  including  hard/fioppy 
disk  drive  control,  display  control,  and  printer  control, 
as  well  as  its  GASS  specific  tasks.  For  the  real-time 
processor  and  the  processors  in  the  sensor  nodes,  it  w  as 
desired  to  have  a  streamlined  operating  system  that 
was  smaller  and  faster.  For  this  application  the  pSOS 
operating  system  was  selected.  Manufactured  by 
Software  Components  Group,  pSOS  is  a  real-time 
multitasking  operating  system  that  is  tailored  for  the 
Motorola  68000  family  of  microprocessors. 

4.  Programming  Language 

Although  some  assembly-language  programming 
was  required  for  this  type  of  system,  the  design  goal  was 
to  use  a  high-level  programming  language  whenever 
possible.  High-level  languages  permit  easier  system 
development  and  provide  much  easier  system  modifi¬ 
cation  and  modernization.  The  language  chosen  for 
this  system  was  Kemighan  and  Ritchie's  "C."  C  is 
an  excellent  language  for  developing  a  system  that 
involves  a  significant  amount  of  input/outpul 
processing  and  special-purpose  equipment  interfacing. 
A  possible  contender  for  the  GASS  programming 
language  choice  was  Ada,  the  Department  of 
Defense’s  (DoD)  standard  programming  language 
for  real-time  embedded  systems.  Even  though  Ada 
has  been  used  by  many  DoD  contractors  and  is  selected 
as  the  programming  language  for  the  Space  Station, 
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Columbus67,  Ada  has  only  recently  been  considered  a 
mature  programming  language62' M’68'69.  Reported 
problems  with  Ada  include  difficulty  in  obtaining 
compilers  for  microprocessors  and  differences  in  inter¬ 
preting  the  language  between  validated  compilers;  also 
the  code  produced  is  too  large  and  slow  for  embedded 
systems.  Ada  was  considered  to  be  inappropriate  forusc 
in  GASS  due  to  the  lack  of  familiarity  by  the  design 
team  and  to  the  difficulties  reported  by  many  large 
government  contractors. 

III.  System  Details 

A.  Hardware 

GASS  is  comprised  of  three  major  subsystems  as 
illustrated  in  Figure  5.  These  subsystems  are  the  Survey 
Control  Subsystem  (SCS);  the  Survey  Analysis 


Subsystem  (SAS);  and  the  Remote  Sensor  Sub¬ 
system  (RSS),  which  is  comprised  of  six  remote  sensor 
systems  (RSS1  through  RSS6). 

The  SCS  is  the  central  control  point  of  GASS.  This 
subsystem  collects  data  from  the  RSS,  stores  the  col¬ 
lected  data  on  magnetic  tape,  and  displays  the  necessary 
survey  status  information  for  the  GASS  operator  and 
the  Project  MAGNET  aircraft  pilot.  The  SCS  is 
designed  to  collect  and  store  all  system  data  at  rates  of 
1,  2,  4,  8,  or  16  times  a  second. 

The  SAS  provides  the  capability  to  perform  in-flight 
analysis  on  the  data  being  collected  and  to  display  the 
results  graphically.  Each  of  the  six  remote  sensor  sys¬ 
tems  are  comprised  of  a  remote  sensorcontroller  (RSC), 
sensors,  and  sensor  supporting  instruments.  The  RSCs 
in  the  remote  sensor  systems  are  identical,  with  the 
exception  of  the  special  interface  cards  required  for 
the  various  sensors.  The  primary  communications  bus 
for  GASS  is  a  dual-redundant  MIL-STD-1553B  serial 
data  bus  that  connects  to  the  SCS,  the  SAS,  and  each 
RSC.  Other  data  buses  are  used  within  the  SCS,  the 
SAS,  and  each  remote  sensor  system  as  required  by 
their  associated  equipment. 

1.  SCS/SAS  and  the  1553  Data  Bus 

The  SCS  and  SAS  subsystems  are  illustrated  in 
Figure  6.  The  SCS  consists  of  the  survey  control  com¬ 
puter,  a  9-track  tape  recorder,  an  operator  console,  a 
graphics  display,  the  project  display,  the  navigation 
display,  the  pilot  display,  and  a  printer.  The  survey 
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Figure  6.  Survey  control  and  analysis  subsystems. 
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control  computer  is  a  Plessey  CS-10  computer 
system,  with  a  Plessey  68-22M  CPU  card  and  a  Plessey 
68-25M  CPU  card.  The  68-22M  CPU  card  is  used  for 
the  operator  interface  and  system  control  functions.  The 
68-25M  CPU  card  provides  an  interface  between 
the  RSS,  the  tape  drive,  and  the  operator.  The  68-25M 
card  interface  to  the  operator  is  via  a  global  memory 
card  that  is  accessible  by  the  68-22M  CPU  card.  Both 
CPU  cards  arc  based  on  a  Motorola  68020  micro¬ 
processor  with  a  Motorola  68881  co-processor.  The 
operator,  graphics,  project,  and  navigation  displays  are 
Tektronics  SF4208  graphics  terminals.  The  pilot  display 
is  an  RGB  (red-grecn-bluc)  display  mounted  in  the 
cockpit  of  the  aircraft.  This  display  provides  the  pilot 
with  the  survey  route  and  other  related  information.  The 
primary  function  of  tire  SCS  is  to  collect  data  from 
the  RSS  over  the  1553  data  bus  and  to  store  this  data  on 
tape.  The  SCS  also  provides  survey  navigation  informa¬ 
tion,  GASS  equipment  status,  backup  system  timing, 
and  operator  system  control  functions. 

The  S  AS  consists  of  the  survey  analysis  computer,  an 
operator  console,  a  graphics  display,  and  a  9-track  tape 
recorder.  The  primary  purpose  of  the  SAS  is  to  provide 
the  operator  access  to  the  GASS  survey  data  base  so  that 
in-flight  data  analysis  may  be  performed.  As  shown  in 
Figure  6,  switches  SW1  and  SW2  allow  either  the  SCS 
or  the  SAS  to  operate  die  project,  navigation,  and  pilot 
displays.  The  SAS  hardware  is  identical  to  the  SCS, 
enabling  the  SAS  to  operate  GASS  in  the  event  of  a 
catastrophic  failure  of  the  SCS. 

The  MIL-STD-1553B  data  bus  is  a  serial  data  bus 
with  a  1  -MHz  maximum  bit  rale.  The  dual -redundant 
configuration  of  thisdatabusisusedinGASS.This  con¬ 
figuration  provides  a  dual  path  for  all  communications 
between  the  SCS/SAS  and  the  RSCs.  In  the  event  that 
one  of  the  redundant  buses  fails,  GASS  will  automati¬ 
cally  switch  to  the  secondary  bus  without  loss  of  data. 
The  1553B  data  bus  also  provides  the  feature  that  a 
failure  of  an  individual  processor  connected  to  the  bus 
will  not  disable  the  bus. 

2.  System  Timing 

An  accurate  time  reference  for  GASS  is  absolutely 
crucial  to  enable  post-processing  of  the  geophysical 
data  collected.  Accurate  time  references  arc  contained 
in  all  processing  units:  the  SCS,  ihcSAS.andcachRSC. 
Since  each  of  these  eight  units  contains  its  own  timing 
device,  some  method  of  assuring  synchronization 
between  all  devices  is  required.  The  Precise  Time  and 
Time  Interval  (PTTI)  interface  provides  time  synchro¬ 
nization  between  all  processing  systems  in  GASS. 
PTTI  provides  time  synchronization  once  every 
minute  to  ,hc  SCS,  the  SAS,  and  each  RSC.  This  is 
accomplished  through  three  lines:  the  binary  coded 


decimal  (BCD)  line,  the  pulse  per  minute  (PPM)  line, 
and  the  liming  fault  line.  The  BCD  line  provides  the 
current  time  stamp  encoded  in  binary  coded  decimal. 
The  PPM  line  provides  the  timing  mark  for  the  time 
issued  by  the  BCD  line.  The  timing  fault  line  indicates 
the  source  of  the  PTTI  signals.  During  normal  opera¬ 
tions  the  PTTI  signals  arc  derived  from  the  global 
positioning  system  (GPS)  through  the  PTTI  interface 
custom-built  by  NORDA.  In  the  event  that  the  GPS 
receiver  fails  to  produce  the  PTTI  signals,  the  timing 
fault  line  is  asserted  by  the  SCS,  and  the  SCS  takes 
control  of  the  time  synchronization  function.  In  this 
mode  the  SCS  sends  the  time  stamp  to  the  SAS  and  each 
RSC  over  the  1553  serial  data  bus,  and  then  issues  the 
timing  mark  over  the  PPM  line. 

3.  Remote  Sensor  Subsystem 

The  RSS  consists  of  all  six  RSCs  and  their  associated 
sensors.  The  RSCs  are  custom-built  VME  chassis 
manufactured  by  NORDA.  They  provide  the  power 
supply  and  framework  to  mount  the  processor  and 
interface  cards  required  to  operate  an  individual  RSS. 
Each  RSC  contains  a  Plessey  68-25M  CPU  card,  an  SCI 
Corporation  1553B  serial  interface  card,  and  any  inter¬ 
face  cards  required  by  the  sensors  of  a  particular  RSS. 
Sensor  interface  cards  include  custom  parallel,  custom 
serial,  1553B  serial,  AR1NC-419,  synchro,  GPIB,  and 
RS422  interfaces.  The  following  paragraphs  describe 
the  components  of  each  RSS. 

RSS  1  (Fig.  7)  contains  RSC  1 ,  a  Rosemount  1 50 1  AT 
precision  barometric  altimeter,  a  Rockwell  GPS-3A 
receiver,  and  the  NORDA  PTTI  interface.  The  altim¬ 
eter  provides  altitude  in  feet  to  the  RSC  through  a 
parallel  interface.  The  Rosemount  altimeter  is  the  most 
accurate  barometric  source  for  altitude  on  the  aircraft. 
The  GPS  receiver  provides  latitude,  longitude,  altitude. 


Figure  7.  RSS  I  interface  diagram. 
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and  heading  to  the  RSC  through  an  independent  1553 
serial  bus.  The  GPS  receiver  also  provides  the  signals 
required  by  the  PTTI  interface  to  provide  system  syn¬ 
chronization.  The  GPS  receiver  provides  the  most 
accurate  aircraft  position  information  in  the  system.  It 
calculates  aircraft  position  through  communications 
with  four  satellites  (normal  operation)  or  through 
communications  with  three  or  less  satellites  and  a 
barometric  altitude  input.  Barometric  altitude  is  sup¬ 
plied  by  the  SCS  over  the  1553  data  bus  to  RSC1. 

RSS2  (Fig.  8)  contains  RSC2,  an  AAU-21  baro¬ 
metric  altimeter,  and  two  Litton-72  inertial  navigation 
systems  (INS).  The  AAU-21  altimeter  provides  altitude 
in  feet  to  RSC2  through  a  parallel  interface.  Each 
Litton  INS  provides  heading,  pitch,  roll,  latitude,  lon¬ 
gitude,  north  velocity,  east  velocity,  ground  speed,  and 
drift  angle  to  RSC2  through  an  ARINC-419  serial 
interface  and  a  Synchro  interface.  These  devices  are 
part  of  the  aircraft  navigation  system  and  are  not 
controlled  by  GASS.  The  barometric  altitude  data 
required  by  the  Litton  INSs  is  provided  by  the  aircraft's 
systems,  independent  of  GASS. 

RSS3  (Fig.  9)  contains  RSC3,  a  Texas  Instruments 
ASQ-81  scalar  magnetometer,  two  Hewlett-Packard 
HP3570B  frequency  counters,  a  Gould  RS3200  strip- 
chart  recorder,  and  an  RMS  Instruments  automatic 
aeromagnetic  digital  compensator.  The  ASQ-81  magne¬ 
tometer  detects  local  magnetic  field  intensity  using  a 
sensor  head  in  the  tail  of  the  aircraft.  It  produces  two 
signals:  the  Larmor  frequency  and  the  bandpass  output. 
The  Larmor  frequency  is  a  frequency  between  0.6  and 
2.2  MHz  that  is  proportional  to  magnetic  field  intensity. 
The  Larmor  frequency  is  measured  by  the  HP5370B 
frequency  counters  and  input  to  RSC3  over  an  HPIB 
data  bus.  Two  frequency  counters  were  required  to 
provide  the  16-Hz  maximum  sampling  rate  required  of 
the  system.  An  individual  HP5370B  frequency  counter 


Figures  RSS2  interface  diagram. 


is  capable  of  a  maximum  sampling  rate  of  only  1 0  Hz  in 
this  configuration.  The  bandpass  output  is  a  signal  that 
is  proportional  to  the  rate  of  change  of  the  local  mag¬ 
netic  field  intensity.  This  signal  is  input  to  RSC3  through 
an  analog  to  digital  converter  card.  The  strip-chart 
recorder  provides  the  GASS  operator  with  a  quick-look 
display  of  both  outputs  of  the  scalar  magnetometer.  The 
digital  compensator  provides  magnetically  compen¬ 
sated  total  field  and  gradient  signals  to  RSC3  through 
a  parallel  interface.  It  derives  these  signals  from  the 
ASQ-81  scalar  magnetometer's  Larmor  frequency 
signal  and  the  X,  Y,  and  Z  axis  magnetic  intensities 
from  the  vector  magnetometer  in  RSS4. 

RSS4  (Fig.  10)  contains  RSC4,  a  Honeywell  H-423 
ring  laser  gyro  (RLG),  a  Honeywell  electronically 
suspended  gyro  (ESG),  a  NAROD  vector  magne¬ 
tometer,  and  three  HP3457A  multimeters.  The  RLG 
provides  latitude,  longitude,  pitch,  roll,  and  true 
heading  to  RSC4  through  an  independent  1553B  serial 
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Figure  9.  RSS3  interface  diagram. 
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data  bus.  The  ESG  provides  latitude,  longitude,  pitch, 
roll,  and  true  heading  to  RSC4  through  a  special  serial 
interface.  RSC4  provides  both  the  RLG  and  the  ESG 
with  barometric  altitude  supplied  by  the  SCS.  The 
vector  magnetometer  produces  three  voltages 
corresponding  to  the  orthogonal  magnetic  field  vector 
intensities.  These  voltages  are  measured  with  the  digital 
multimeters  and  sent  to  RSC4  over  an  HPIB  data  bus. 
These  voltages  are  also  supplied  to  the  d-'gital  compen¬ 
sator  in  RSS3. 

RSS5  (Fig.  11)  contains  RSC5,  an  OPTECH  501-A 
laser  altimeter,  and  a  Honeywell  APN-222  radar 
altimeter.  The  laser  altimeter  provides  altitude  in  meters 
to  RSC5  through  a  parallel  interface.  The  radar  altime¬ 
ter  provides  altitude  in  feet  to  RSC5,  also  through  a 
parallel  interface.  The  laser  altimeter  is  the  most  accu¬ 
rate  source  of  altitude  in  GASS  for  low  altitudes,  and  the 
radar  altimeter  is  the  most  accurate  for  high  altitudes. 

RSS6  (Fig.  12)  contains  RSC6,  the  Hydrographic 
Airborne  Laser  System  (HALS),  and  the  Airborne 
Multispcctral  Pushbroom  System  (AMPS).  HALS  is 
under  development  by  NORDA  and  the  Naval  Air 
Development  Center  (NADC)  and  is  a  laser-based 
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Figure  1 1  RSS5  interface  diagram. 
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system  for  determining  shallow-water  depth70.  AMPS 
is  under  development  by  Lockheed  through  NASA 
and  is  a  system  that  determines  shallow-water  depths 
using  multispectral  images  of  the  ocean  surface.  These 
systems  will  collect  and  store  their  data  independently 
from  GASS,  and  they  will  have  their  own  operator  on 
the  aircraft.  GASS  provides  HALS  and  AMPS  with  a 
time  stamp  through  a  parallel  interface,  and  with  lati¬ 
tude,  longitude,  height,  true  heading,  pilch,  and  roll 
through  a  serial  interface. 

B.  GASS  Software 

Figure  1 3  illustrates  the  GASS  software  distribution. 
GASS  software  is  functionally  and  physically  distrib¬ 
uted  among  the  processors  in  the  SCS,  the  SAS,  and  the 
RSCs.  All  real-time  or  near-real-time  functions  arc 
handled  by  the  68-25M  CPU  cards  in  the  SCS,  the  SAS, 
and  the  RSCs  under  a  Software  Components  Group  Inc. 
operating  system  called  pSOS.  All  nonrcal-time  func¬ 
tions  are  handled  by  the  68-22M  CPU  cards  in  the  SCS 
and  the  SAS  under  a  Motorola  Unix  V.3  operating 
system.  The  software  is  functionally  distributed  into 
the  following  areas:  Survey  Control  System,  SCS  Real 
Time  Front  End  (RTFE),  Survey  Analysis  System, 
SAS  RTFE,  and  the  RSCs. 

The  SCS  software  is  responsible  for  the  operator 
interface,  system  control,  navigation,  displays,  and 
printer  functions.  The  SCS  RTFE  software  is  respon¬ 
sible  for  the  1553  communication,  data  handling, 
message  processing,  tape  drive  control,  and  time¬ 
keeping  functions.  The  SAS  software  is  similar  to  that 
of  the  SCS,  but  it  does  not  incorporate  the  system 
control  and  navigation  functions.  The  SAS  software 
includes  graphics  and  data  base  functions  not  in  the 
SCS  software.  The  SAS  RTFE  software  is  almost 
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Figure  13.  GASS  software  distribution. 
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identical  to  the  SCS  software.  The  RSC  software  is 
responsible  for  time  keeping  and  1553B  data  bus 
communications  for  all  RSCs.  It  also  performs  the 
functions  of  sensor  control  and  sensor  data  pre¬ 
processing  for  the  sensors  in  a  particular  RSS. 

The  software  in  the  six  RSCs  is  physically  separated 
from  the  RTFEs  in  the  SCS  and  S  AS  by  the  1 553B  serial 
bus.  The  software  in  the  SCS  and  SAS  is  physically 
separated  from  the  respective  RTFEs  by  the  SCS  and 
the  SAS  Global  Memory  Cards,  with  the  exception  of  a 
"mailbox"  interrupt  line.  The  SCS  and  SAS  software  is 
stored  on  hard  disk  and  is  loaded  into  RAM  for  opera¬ 
tion.  Both  of  the  Plessey  CS-10  computer  systems 
contain  the  software  for  the  SCS  and  the  SAS,  and  each 
may  be  booted  to  perform  either  function.  The  software 
for  the  SCS  RTFE,  the  SAS  RTFE,  and  the  RSCs  is 
contained  in  ROM  in  the  respective  68-25M  CPU  cards, 
and  is  loaded  into  RAM  for  operation.  The  ROM  used 
for  the  SCS  and  SAS  RTFE  contains  the  software  for 
both,  allowing  either  CS-10  computer  system  to  operate 
as  cither  the  SCS  or  the  SAS.  The  ROMs  for  the  RSCs 
contain  the  software  for  all  six  RSCs.  A  jumper  on  a 
parallel  port  of  the  RSC  is  used  to  inform  the  RSC  boot 
software  as  to  which  RSC  it  is  in  upon  power-up.  The 
boot  software  will  load  the  software  for  that  RSC 
into  RAM. 

1.  Survey  Control  Subsystem  Software 

The  SCS  software  (Fig.  1 4)  consists  of  the  navigation 
history,  navigation  control,  display  control,  data 
print,  mailbox  control,  and  man-machine  interface  tasks. 
The  navigation  history  task  keeps  a  record  of  the 


survey's  navigation  information  on  the  computer's 
floppy  drive.  This  informationis  used  to  quickly  resume 
a  survey  should  an  SCS  failure  occur.  The  navigation 
control  task  is  responsible  for  computing  the  deviation 
from  the  actual  aircraft's  track  to  the  desired  survey 
track.  The  resulting  information  is  displayed  on  the 
navigation  and  pilot  displays.  The  display  control  task 
is  responsible  for  driving  the  non-interactive  naviga¬ 
tion,  project,  and  graphics  displays  (the  pilot  display  is 
a  slave  under  the  control  of  the  navigation  display).  The 
data  for  these  displays  are  obtained  from  the  SCS  global 
memory.  The  data  print  task  creates  printouts  of  data 
and  system  parameters,  as  directed  by  the  operator.  The 
SCS  mailbox  control  task  provides  for  the  interface 
between  the  SCS  software  and  the  SCS  RTFE  software. 
The  man-machine  interface  task  controls  all  interactions 
with  the  operator  via  the  operator  console.  Its  functions 
include  on-line  help,  configuration  and  control  of  sys¬ 
tems  sensors,  generation  and  editing  of  survey  tracks, 
display  configuration,  special  events  log,  and  print 
control.  With  the  exception  of  the  mailbox  interrupt  line, 
all  communications  between  the  SCS  software  and  the 
SCS  RTFE  software  are  via  the  SCS  global  memory. 

2.  SCS  Real-Time  Front-End  Software 

The  SCS  RTFE,  software  (Fig.  15)  consists  of  the 
1553  bus  manager,  message  processor,  tape  manager, 
and  time  tasks.  The  1553  bus  manager  task  in  the  SCS 
RTFE  controls  all  communications  on  the  1 553B  dual- 
redundant  serial  data  bus.  It  operates  the  SCS’s  SCI 
1553B  interface  card  in  the  bus  controller  mode,  polling 
each  RSC  for  status  and  data.  The  message  processor 
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Figure  14  Survey  control  subsystem  software  (  UNIX  operating  system). 
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Figure  IS.  Real  time  front  end  software  (pSOS  operating  system). 


task  handles  all  communications  to  and  from  the 
1553  bus  manager  task.  It  handles  the  formatting  and 
routing  of  all  messages  and  data.  It  sends  sensor  control 
commands  to  the  bus  manager,  receiving  sensor  status 
messages  and  sensor  data  from  the  bus  manager,  and  for 
routing  sensor  data  to  the  tape  manager  task  and  the 
SCS  global  memory.  The  tape  manager  task  formats  all 
data  received  from  the  message  processor  and  for 
operation  of  the  magnetic  tape  drive.  The  lime  task  in 
the  SCS  updates  the  RTFE's  processor  clock  using  the 
PTTI  signal.  This  task  also  provides  the  current  system 
time  to  the  operator  via  the  SCS  global  memory.  The 
SCS  RTFE  time  task  serves  as  the  backup  for  the  PTTI 
signal  in  GASS.  If  this  task  recognizes  a  loss  of  the 
PTTI  signal,  then  it  will  take  over  the  system  timing 
tuncuon  by  asserting  the  PTT!  fault  line,  generating 
timing  sync  pulses  over  the  PTTI  interface  and  send¬ 
ing  the  current  time  stamp  to  the  bus  manager  for 
transmission  to  all  RSCs. 

3.  Remote  Sensor  Controller  Software 

The  remote  sensor  controller  software  (Fig.  16) 
consists  of  the  1553  bus  manager,  message  processor, 
time  manager,  and  sensor  control  tasks.  The  bus  man¬ 
ager  task  in  the  RSCs  buffers  and  transmits  the  data  and 
messages  received  from  the  message  processor.  It  also 
receives  sensor  control  information  from  the  1553  bus 
and  passes  this  to  the  message  processor.  The  RSC 
bus  manager  * ;  ;k  operates  the  SCI  1 553B  interface  card 
in  the  remote  terminal  mode.  The  message  proccssc 
task  processes  all  messages  between  the  sensor  control 
tasks,  the  bus  manager  task,  and  the  time  manager  task. 
The  time  manager  task  updates  the  RSC  processor's 
clock  using  the  PTTI  signals.  If  the  PTTI  fails,  then  the 


Figure  16.  Remote  sensor  controller  software  (pSOS  operating 
system). 


time  manager  task  will  issue  an  alarm  to  the  message 
processor  for  transmission  to  the  SCS.  The  RSC  soft¬ 
ware  contains  a  separate  sensor  control  task  for 
every  sensor  or  instrument  in  the  particular  RSC. 
Each  sensor  control  task  is  responsible  for  sensor 
operation  and  control  (via  commands  from  the  SCS), 
sensor  alarm  processing,  data  acquisition,  and  data 
checking/formatting. 

4.  Survey  Analysis  System  and 
SAS  RTFE  Software 

The  SAS  RTFE  software  (Fig.  17)  is  similar  to  the 
SCS  RTFE  software,  except  that  the  tape  manager  task 
is  included  in  the  message  processor  task,  and  th?  bus 
manager  operates  the  SCI  1553B  interface  card  in  the 
bus  analyzer  mode.  The  bus  analyzer  mode  allows  only 
the  SAS  to  monitor  the  1553B  data  bus.  A  separate  tape 
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Figure  17.  Survey  analysis  subsystem  software. 


manager  task  is  not  needed,  since  the  SAS  will  only 
retrieve  data  from  the  tape  recorder  and  will  not  send 
data  to  the  recorder.  The  SAS  software  consists  of  the 
man-machine  interface,  SAS  mailbox  control,  data 
handler,  que  dump,  and  plot  tasks.  As  with  the  SCS,  the 
man-machine  interface  provides  all  interface  between 
the  operator  and  the  SAS.  This  task  allows  the  operator 
to  control  data  acquisition  from  the  1553B  bus  and  tape 
drive,  to  select  plotting  options,  and  to  select  data 
computations.  The  SAS  mailbox  control  task  provides 
the  interface  between  the  SAS  software  and  the  SAS 
RTFE  software.  The  plot  tasks  can  generate  real-time 
plots  from  the  data  base  or  from  off-line  plots  from  data 
stored  ;n  Tiles.  The  nlots  created  can  be  displayed  on  the 
graphics  display  or  on  the  printer.  The  data  handler  task 
routes  data  from  the  SAS  RTFE  to  either  the  data  base 
or  to  disk  files.  The  que  dump  task  routes  the  operator- 
specified  data  from  cither  the  disk  files  or  the  data  base 
to  the  plot  tasks. 

C.  GASS  Data  Flow 

Figure  18  illustrates  the  typical  (low  path  of  data 
through  GASS.  Data  originate  at  an  individual 
sensor  and  arc  sent  to  an  RSC  via  the  sensor's  interface 
card.  The  sensor  interface  card  converts  the  data  from 
the  sensor  into  a  format  that  can  be  used  by  the  RSC's 
68-25M  CPU  card.  The  sensor  manager  task  receives 
the  data  from  the  sensor  interface  card  and  sends  it  to  the 
message  processor  task.  The  message  processor  task 
properly  formats  the  data  and  sends  it  to  the  bus  man¬ 
ager  task.  The  bus  manager  collects  the  data  from  all 


sensors  into  a  buffer.  When  the  RSC  is  polled  by  the 
SCS,  the  bus  manager  sends  all  of  the  data  currently  in 
its  buffer  to  the  1553B  interface  card  for  transmission 
on  the  1553B  data  bus.  The  SCS  RTFE  bus  manager 
task  receives  the  data  transmitted  on  the  bus  by  the  RSC 
from  the  SCS's  1553B  interface  card.  The  bus  manager 
task  passes  the  data  to  the  SCS  RTFE  message  proces¬ 
sor  task.  The  message  processor  routes  all  the  sensor 
data  to  the  tape  manager  task  and  to  the  sensor  data  area 
in  the  SCS  global  memory  card.  The  tape  manager  task 
formats  the  data  and  sends  them  to  the  Pcrtec  interface 
card,  which  in  turn  sends  the  data  to  the  tape  drive  for 
recording.  The  display  control  task,  located  in  the  SCS 
CPU  card,  retrieves  the  data  placed  in  the  SCS  global 
memory  card  by  the  SCS  RTFE  CPU  card,  formats  it, 
and  sends  it  to  the  displays  via  a  serial  interface. 

IV.  Summary 

This  study  evaluates  and  applies  the  state  of  the  art  of 
distributed  real-time  system  design.  The  knowledge 
base  for  distributed  design  is  largely  empirical,  and  few 
metrics  are  available  for  evaluating  the  economics  of  a 
particular  design.  The  significant  gains  of  a  distributed 
design  over  a  centralized  design  are  an  increase  in 
reliability,  flexibility,  and  expandability.  Software 
development  is  the  most  difficult  and  the  most  expen¬ 
sive  part  of  distributed  systems  development.  While 
distributed  systems  can  realize  a  savings  in  hardware, 
the  cost  of  the  software  could  easily  offset  this  savings 
if  the  system  design  is  too  complex.  It  is  important  to 
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realize  that  the  only  widely  accepted  method  for  ensur¬ 
ing  reliability  of  software  is  through  exhaustive  testing. 
However,  some  of  the  costs  of  software  debugging  can 
be  reduced  by  following  a  rigorous  software  quality 
assurance  plan. 

A  systematic  approach  to  the  design  of  GASS 
involved  first  the  identification  of  the  system's  require¬ 
ments  and  major  design  restrictions.  Then,  a  methodical 
analysis  of  available  architecture  options  was  made  to 
produce  a  design  that  meets  both  the  requirements  and 
restrictions.  The  major  elements  of  the  system’s  archi¬ 
tecture  are  the  number  of  processors,  the  way  these 
processors  are  distributed  and  interconnected  in  the 
system,  and  the  distribution  of  the  software  tasks.  This 
study  revealed  that  the  design  of  embedded  real-time 
distributed  systems  is  largely  application  specific;  the 
design  of  GASS  given  in  this  paper  offers  one  possible 
solution  to  the  given  design  parameters. 

V.  Recommendations 

A.  Further  Study 

Once  GASS  is  completed  and  has  undergone  suc¬ 
cessful  functional  testing,  performance  testing  should 
be  done  to  evaluate  the  system's  design  and  its  potential 
for  expansion.  One  key  performance  criterion  is  the 
loading,  or  the  "busy  time"  of  the  system’s  processors. 
This  measure  will  reveal  critically  loaded  processors,  if 
they  exist,  and  will  also  provide  an  idea  of  how  much 


extra  load  the  system  can  handle.  If  there  are  critically 
loaded  processors  in  the  system,  then  the  problem  can 
probably  be  remedied  by  a  different  distribution  of 
sensors  in  the  RSCs.  Another  significant  measure  is  the 
latency  time  of  the  network  bus.  Excessive  bus  latency 
can  adversely  affect  the  navigation  function  of  the 
system,  since  GASS  will  be  used  on  an  aircraft.  At 
typical  survey  speeds  of  200  knots,  15  seconds  is 
equivalent  to  0.95  miles  of  travel.  Probably  the  most 
significant  measure  of  system  performance  at  this  point 
is  that  of  measurement  time  skew.  Even  though  the 
system  is  time  synchronized  and  sensor  acquisition 
tasks  are  initiated  within  a  few  microseconds  of  each 
other,  a  time  skew  still  exists  between  the  actual  meas¬ 
urements.  Part  of  this  skew  can  be  accounted  for  by  the 
fact  that  the  acquisition  tasks  for  different  sensors 
require  varying  lengths  of  time  to  actually  trigger  their 
sensors.  The  major  contributor  to  the  time  skew,  and 
also  the  hardest  to  measure,  is  the  time  required  for  each 
instrument  to  perform  a  measurement  once  triggered. 
Some  instruments,  the  barometric  altimeters,  for 
example,  provide  data  almost  instantly  after  triggering 
of  the  acquisition  task.  Other  instruments,  such  as  the 
frequency  counters  used  for  the  ASQ-81  magne¬ 
tometer,  may  take  almost  the  entire  sample  interval 
(when  at  an  8-  or  16-Hz  sampling  rate)  to  make  the 
measurement.  These  time  skews  need  to  be  accurately 
determined  so  that  they  can  be  accounted  for  during  post 
processing  of  the  GASS  data. 


17 


B.  Future  System  Enhancements 

The  GASS  architecture  will  allow  very  easy  modifi¬ 
cation  and  modernization  of  the  system.  If  processors 
become  overloaded,  then  the  system  can  be  easily 
reconfigured  to  distribute  the  load  properly.  If  load 
distribution  is  not  an  adequate  solution,  then  more 
processors  could  be  added  to  the  existing  nodes,  or  extra 
nodes  can  be  added  to  the  system.  If  bus  latency 
becomes  a  problem,  then  bus  performance  can  be 
improved  by  using  a  token  passing  MAP  instead  of  the 
currently  used  controller  scheme.  In  the  event  of 
severe  bus  loading  problems,  the  system  could  be 
segmented  into  several  buses  by  adding  more  bus 
interface  cards  to  the  SCS,  or  the  entire  bus  system 
could  be  upgraded  to  a  faster  fiber-optic  media.  The 
system's  fault  detection  capabilities  can  be  improved 
easily  by  incorporating  cross-instrument  data  testing, 
as  discussed  by  Bourgeois48.  System  availability  can  be 
improved  by  altering  the  current  RSC  software  structure. 
The  current  design  allows  any  of  the  RSC  processor 
cards  to  be  used  in  any  RSC.  This  design  could  be 
improved  further  by  configuring  the  RSC  software  to 
allow  execution  ot  any  combination  of  the  system's 
sensor  tasks.  With  this  change,  many  of  the  sensors  of 
a  failed  RSC  could  be  relocated  to  an  operational  RSC. 
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area  of  real-time  distributed  microprocessor  systems.  Specific  topics  include  the  goals  of  distributed  system  design,  the  qualitative 
value  of  distributed  system  design,  and  reliable  design  techniques  for  the  hardware  and  software  in  distributed  systems.  This  technology 
review  provides  a  foundation  for  the  GASS  design. 

The  system  design  decisions  made  for  GASS  are  detailed,  and  the  system’s  architecture  is  described.  Detailed  drawings  and  descriptions 
of  the  hardware  and  software  for  the  final  GASS  design  are  also  included.  Recommendations  are  made  for  possible  system  enhancements 
and  for  areas  that  require  further  investigation. 
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